Cloudflare One — ZTNA Demo Cheat Sheet

~27–32 min · Mixed technical + leadership audience · Conversational

Legend: ▶ click / nav · 💬 spoken line · $ terminal · ⏸ pause · ➡ transition

Pre-demo setup checklist

0. Introduce Cloudflare + frame the architecture (~11 min, before the dashboard)

▶ Open cf-demo-app.dustinburke23nc.workers.dev/vpn-vs-zerotrust in a fresh tab BEFORE logging into Cloudflare One. Page loads on Tab 1 ("The full platform") by default. Keep both tabs open.

Section flow: 0a SASE platform intro · 0b User + server connectivity walkthrough · 0c VPN-vs-Zero Trust architectural argument. By the time you switch tabs to the dashboard, the customer has the full mental model.

→ Page opens on Tab 1: "The full platform." Pause two seconds. Let the diagram register.

"Quick reset on what Cloudflare actually is, because most people know us from one angle. One platform, three things in scope. On the left — the people who need protection. Employees, contractors, AI agents now. Their devices. The locations they work from. On the right — what they're trying to reach. Your apps, your infrastructure, your networks. Everything in the middle is what we do."

→ Point at the six orange hexagons in the center. Walk them slowly.

"Six capabilities, one network. Zero Trust security — identity, access, posture. Network as a service — replacing MPLS, VPN concentrators. AI security — for the new threats that didn't exist two years ago. Manage and compose — APIs, Terraform, dashboard. AI-powered platform — Workers AI, Vectorize, agentic infrastructure. Integrate and program — extend any of this with code at the edge. Same control plane, same logs."

→ Point at the three orange tiles along the bottom.

"Three promises. End-to-end visibility on every flow. Consistency across all on-ramps. Global distribution at 330+ cities. Most vendors do half of this and partner for the other half. We do the whole thing on one network. That's the difference between SASE as marketing and SASE as architecture."
🎬
Stay on the same page — Tab 1 already has the on-ramps
→ Tab 1: "Cloudflare platform & connectivity"
3 user cards on the left, 3 server cards on the right, Cloudflare in the middle. Click each card as you tell its story. "Animate all" cycles through all six if you'd rather narrate over the animation. Standalone URL still works: cf-demo-app.dustinburke23nc.workers.dev/connectivity

→ Still on Tab 1. After narrating the orange chip row at the top (the 6 capabilities + 3 promises), shift the customer's eye down to the 3 column diagram. Let them see the layout for a beat — six cards, three on each side, Cloudflare in the middle.

"Quick walk through both sides — because the next question is always 'how does the user actually connect, and how does the server side hook in?' Three on-ramps per side. Let me show you each one — they'll match up with whatever your environment looks like."

⚡ USER SIDE — 3 patterns

→ Click card U1 (Managed employee laptop).

"Pattern one — managed employee. Corporate laptop, fully under IT control.

We push our WARP client through your MDM — Intune, Jamf, Workspace ONE, whatever you use — and the user never has to touch it. Once it's running, every request they make gets routed through the nearest Cloudflare PoP.

Identity, posture, policy — all happen there, automatically. Single sign-on with your IdP, device posture check, and the policy decision is made at the edge before the traffic ever reaches your apps.

This is the default path for managed workforces."

→ Click card U2 (Contractor / BYOD).

"Pattern two — contractor or BYOD. The contractor's on their own laptop. You can't push an MDM agent. You can't reimage their machine. They might be in a different country.

Two options.

Either they install WARP voluntarily if you want full posture visibility, or they just open the app URL in any browser and log in with their own identity — Google, GitHub, email one-time PIN, whatever you allow.

No agent. No install. Nothing on their machine.

Pair this with Browser Isolation if you want them to interact with internal data but never have it actually touch their device — every keystroke, every screen pixel, stays on Cloudflare's side."

→ Click card U3 (Branch office / site).

"Pattern three — branch office. You don't ask every user at the site to install something. You connect the network from the edge.

The router at the branch — Palo Alto, Fortinet, Cisco, Meraki, AWS VPN Gateway, whatever you have — builds an IPsec or GRE tunnel to Cloudflare. Two endpoints, shared key, done.

Once that tunnel's up, every device behind that router gets policy enforcement. Laptops, phones, printers, IoT devices, contractors plugged in at the desk — all of it.

This is what replaces MPLS and site-to-site VPN concentrators. If you're paying a telco for MPLS today, this is the conversation that ends that bill."
The user-side punchline: "Three different on-ramps. Same security policy hits all three. That matters because your security team writes the policy once, not three times. And when a contractor's status changes, or a device falls out of compliance, or a branch goes offline, the response happens in one place."

⚡ SERVER SIDE — 3 patterns

→ Click card S1 (Single server or VM).

"Pattern one — single server. One app, one box. Could be an EC2 instance, a VM in your data center, a container, anywhere.

You install a small connector called cloudflared on it. Three commands. It dials out to Cloudflare on port 443 and holds a persistent connection.

Nothing inbound from the internet. No public IP. No firewall port to open. No NAT rule. Your app becomes reachable through Cloudflare, and only through Cloudflare.

This is the fastest path from 'we have an internal app' to 'we have a securely reachable app.' You can have it deployed in five minutes."

→ Click card S2 (Whole VPC or subnet).

"Pattern two — whole VPC or subnet. When you've got mixed workloads in a VPC — fifteen apps, three database servers, a couple of windows boxes for RDP — and you don't want to install cloudflared on every one.

You install WARP Connector on one server in the network and tell it 'I represent this whole CIDR range.' Now every server behind it is reachable.

No per-server agents.

Especially good for legacy apps you can't modify, services that need long-lived TCP connections — databases, RDP, SSH, SAP, internal tooling — and any workload where touching the server is out of scope.

Mesh is the variant when you want full peer-to-peer connectivity inside the private network, not just inbound."

→ Click card S3 (Data center or cloud region).

"Pattern three — whole data center or cloud region. Network-level integration.

Same IPsec or GRE pattern as the branch office side, but now on the server end of the network — your data center router or your cloud transit gateway builds the tunnel to Cloudflare.

Or — for very large or latency-sensitive deployments — CNI. Cloudflare Network Interconnect. That's a literal direct connection between your network and ours, bypassing the public internet entirely. AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect, or a physical cross-connect in one of our peering facilities like Equinix.

Magic WAN is the product that orchestrates all of this together — your branches, your data centers, your clouds, all glued together through Cloudflare's backbone. Each site connects to Cloudflare. Cloudflare's backbone is the WAN. No MPLS, no SD-WAN appliances, no per-site mesh tunnels you have to maintain."
The server-side punchline: "Notice what's missing across all three patterns — no public IP exposed, no firewall rule opened, no port forwarded. Every connection from your infrastructure to Cloudflare is outbound-only. The 'door' doesn't exist on the internet. That's the architectural shift — your apps stop being a target because they stop being addressable."
"That's how both sides connect. Three user on-ramps, three server patterns, all converging on the same Cloudflare network in the middle. Same policy engine evaluates all of it. Now let me show you the specific architectural argument for Zero Trust, which is what you're actually here to talk about."

→ Click Tab 2: "What VPN costs you". Walk the red center box, then point at "Your Cloud" on the right.

"Three columns. People on the left, apps on the right, and everything in the middle is what they have to go through to get there.

That middle isn't one product. It's a VPN box, a firewall, a cert store, an MFA appliance. When you outgrow it, you're replacing all of it. Same vendor conversation every three to five years.

And here's the part that gets forgotten — your own cloud takes the same detour. Contractor in Singapore, VPN in Virginia, AWS region right next door to the contractor. Traffic still goes all the way to Virginia and back. M365, Salesforce, same story. Not your apps, still through your box.

Half a second of waiting, every click. That's a design problem, not a vendor problem."

→ Click "What Cloudflare delivers". Let them notice left/right columns are identical, then point at the orange center.

"Same picture. Left didn't move. Right didn't move. The middle isn't a box anymore — it's a network. 330+ cities. San Francisco employee hits San Francisco. Singapore contractor hits Singapore. Nobody travels back to a central office to get checked in."

→ Walk the 8 capabilities. One line each, don't dwell.

"And at that local PoP, eight checks happen in one pass:

  WARP — device healthy.   Identity — Okta, Entra, your existing login.   Access — what you're allowed to reach.   Gateway — web filtering.
  DLP — sensitive data leaving where it shouldn't.   CASB — misconfigs and oversharing in SaaS.   Email Security — phishing caught before it lands.   Browser Isolation — risky sites run in our cloud, never on the laptop.

Not separate products. Same network, same rules, same logs. Same Singapore contractor, same app — now about 200ms. The middle stopped slowing them down."

→ Optional — only if engineers are in the room. Click "Do the math · Latency".

"490 vs 212. We can't break physics — Virginia to Mumbai, the bits still make the trip. About 180ms is the speed of light. Nobody breaks that.

But we change how they make the trip:

  • Public internet → our private backbone. Rush-hour streets to a toll road.
  • Connection stays open instead of rebuilding every time. No setup tax per request.
  • Same data twice? Cached in Mumbai. Second user never crosses the ocean.

That's the 278ms. Per click. Across a workday, real time back."

➡ Switch tab to one.dash.cloudflare.com. Section 1 begins.

1. Opening / Cloudflare One Overview

▶ one.dash.cloudflare.com → Overview (landing page)

"This is the Cloudflare One Overview — the page you land on when you log in. It's designed to answer one question in 10 seconds: is my Zero Trust deployment healthy and being used, or is it just sitting there? Let me walk you through it."

→ Point at the counters at the top of the page

"I just want to touch on a few items on this page — I won't go over all of them, some are self-explanatory. Start at the top. These counters are the pulse check. Users — 7 of 10 seats in use, that tells me adoption. Active devices connected in the last seven days. Targets — private network resources I've registered. Applications — what's protected by Access policies, I have four. And Active Tunnels — outbound connections from my infrastructure to Cloudflare. I'll show those working live in a few minutes."

→ Scroll down to the "Your deployment" flow diagram

"This part is brand new — and honestly, it's one of my favorite things on the platform right now. It's a flow diagram of how traffic actually moves through Zero Trust — users on the left, the policies they pass through in the middle, the applications they reach on the right. Toggle between Access Control mode (who's authorized) and Traffic Flow mode (what's actually moving). Every access request is a line you can trace from person to policy to application. No more stitching logs together to figure out who hit what."

→ Scroll to the Connected Users widget

"Connected Users shows how people are reaching Cloudflare — Device Client only, browser only, or Both. 'Both' is the gold standard — same user, two enforcement paths, fully covered."

→ Scroll to the leaderboards at the bottom

"Finally, quick leaderboards at the bottom — top private apps, top users, top routes, top policy actions. If something looks wrong, I'll see it here before a user even opens a ticket."
"Notice the framing across this whole page — every metric is about users and applications, not networks. That's intentional. Zero Trust starts from identity and what you're trying to reach. Not what subnet you're on."

➡ Now let's go deeper — Insights tells me HOW Zero Trust is actually being used.

2. Analytics Overview

▶ Insights → Overview

"This page tells me quickly whether Zero Trust is actually being used — or just configured and forgotten. Big difference."

Global Status — the sanity check

"Top left. What's enabled, what's active, what's configured. Access apps, Gateway policies, DLP profiles, seats in use. If you onboard a team here, this is where you'd watch adoption climb."

Access — every decision before the app

"The most important section on the page. Every event here is Cloudflare making a decision before the user reaches the app — allowed, denied, and why."

"If it shows up here, identity was evaluated. No anonymous access. No 'once you're in, you're trusted.'"

Proxy and DNS traffic — Gateway working in real time

"This is where SWG and DNS filtering surface. Every HTTP request and DNS query, logged and attributed."

"And here's what lands — Cloudflare doesn't just see an IP. It ties every request back to the user. Not a device. A person."
"Takeaway: visibility. Who accessed what, when, why — one place. No stitching VPN logs, firewall logs, and app logs together at 2 a.m. If somebody asks 'what was Mayah doing yesterday at 3pm?' — that's three filters away."

3. Dashboards

▶ Insights → Dashboards

"Built around how Zero Trust actually works — and the questions teams ask every day. Each dashboard maps to a control plane: Access, Gateway, applications, data security."

4. Logs

▶ Insights → Logs

"Dashboards show trends. Logs show proof. Organized by control plane, so instead of one giant fire-hose, it's broken out by what enforced the decision."

⏸ Pause

"When teams move off traditional firewalls, they always ask: 'where do I see that traffic now?' — This is where."

5. Devices

▶ Team & Resources → Devices

"Device trust. Identity is half the story — we also care about what they're connecting from."

"Devices connect through the Cloudflare One client — formerly WARP. Not a VPN. No network drop-in — traffic goes straight to our edge, policy enforced in real time."

"Because the client runs on the device, we get real context. Enrolled? Healthy? Meets posture? Access decisions are about who you are and what you're using."

▶ Device Enrollment

"Control who's even allowed to enroll. I have it set to my Gmail account, which is only me. Device trust stays intentional, not accidental."

6. Users

▶ Team Resources → Users

"In production you're not managing this list manually — it populates automatically from your identity provider. Okta, Entra, Google Workspace, whatever you're using."

"Once I gave my team access by allowing @cloudflare.com, they were authenticated and populated automatically. I didn't add these."

▶ Click Dustin Burke

"Admins can revoke active sessions. If a device is lost or someone leaves — access cut off immediately. No network changes. No waiting for VPN sessions to time out."

"Risk score lives here too — highlights unusual behavior tied to a user over time. Don't need to open it now, but it's there when teams want to dig deeper."

➡ Devices and users are who and what. Now let's see how they actually connect — without exposing a network.

7. Networks Overview

▶ Networks → Overview

"This is the connectivity layer underneath Access — how users and apps reach each other without exposing the network. Quick actions at the top for tunnels, app publishing, routing. Health metrics on the right. The big idea: users connect to Cloudflare, apps connect to Cloudflare, and policy decides what's allowed — not the network."

8. Connectors + LIVE TUNNEL DEMO (the centerpiece)

▶ Networks → Connectors

"Cloudflare Tunnels — outbound-only connections from the environment up to Cloudflare. No open ports. No exposed IPs. The app connects out. Nothing listens inbound."

"I'm running two connectors here, not one. In production, you never run a single tunnel for an app you care about — primary plus at least one replica. Same tunnel, multiple connectors. If one dies, the other keeps serving." 
$ syscloud

UNIT                          LOAD   ACTIVE SUB     DESCRIPTION
cloudflared.service           loaded active running cloudflared
cloudflared-replica.service   loaded active running cloudflared-replica
2 loaded units listed.
"Two scenarios. First — one connector dies. Then — both die. Two very different stories."

DEMO A — High Availability (one connector dies, traffic keeps flowing)

▶ On the EVE-NG server:

$ systemctl stop cloudflared
"Killing the primary only. In a real outage this could be a host crash, a network blip, anything that takes one connector offline." 
$ syscloud

cloudflared.service           loaded inactive dead    cloudflared
cloudflared-replica.service   loaded active   running cloudflared-replica

▶ Switch to Safari → https://eve-ng.tarheel.us

"The app loads. From the user's perspective, nothing happened. They have no idea a connector just died."

"This is the boring part of HA — and that's exactly the win. When HA is working, the demo is uneventful. The customer sees nothing. The user sees nothing. Just a working app."

▶ Back to dashboard → Networks → Connectors

"One connector degraded, one healthy. Cloudflare routes through the healthy one. No human intervention. No paging. No 3 a.m. phone call."

DEMO B — Full Failure (both connectors die, fail-closed)

▶ On the EVE-NG server:

$ stopcloud
"Now killing the replica too. Both down. Tunnel has zero connectors registered." 
$ syscloud

cloudflared.service           loaded inactive dead cloudflared
cloudflared-replica.service   loaded inactive dead cloudflared-replica

▶ Switch to Safari → https://eve-ng.tarheel.us

"Error 1033 — Cloudflare Tunnel error."

"The tunnel is outbound-only, so when every connector drops, access fails closed. Nothing is exposed. There's no fallback path to the origin. The app is just… gone, from the internet's perspective. It stops AT Cloudflare — not at your tunnel endpoint."

"This is the part traditional architectures get wrong. When a VPN concentrator fails, you usually have a hardware backup, a public IP somewhere, some path back to the network — and that path is the attack surface. Here, when the connectors go down, there's no path at all. Nothing to find. Nothing to attack."

DEMO C — Recovery (both connectors back, traffic restored)

▶ On the EVE-NG server:

$ startcloud

⏸ Wait ~5 seconds, return to dashboard

$ syscloud

cloudflared.service           loaded active running cloudflared
cloudflared-replica.service   loaded active running cloudflared-replica

▶ Dashboard → Networks → Connectors

"Tunnel healthy. Both connectors connected. Uptime climbing."

"The connectors re-established their outbound connections. Access immediately restored. No firewall changes. No inbound ports. No VPN."

"That's Zero Trust in practice: outbound-only connectivity, identity-first access, automatic high availability."

▶ Click the tunnel itself → show both connectors and PoP each is connected to (IAD = Northern Virginia, ATL = Atlanta)

THE ARCHITECTURAL POINT

One down → user sees nothing. HA does its job invisibly.
All down → app vanishes from the internet. Nothing to attack.
Back up → connectors phone home, access restored. No firewall rule changed.

"This is what 'fail closed' actually means. Compare that to a VPN concentrator going down — and the public IP that's still sitting there."

📦 Onboarding internal servers (EC2, on-prem, anywhere) (~2 min — show if asked)

Customer trigger: "OK that's your lab — how would I actually onboard my own EC2 instances?" This is the answer.

▶ Networks → Tunnels → "Create a tunnel" (walk through, don't actually create)

"Three ways to bring internal servers into Zero Trust, depending on what fits your environment. Let me walk through them."

Option 1: Install cloudflared on the instance itself

"The most common pattern. Install our tunnel daemon directly on the EC2 box. Outbound-only port 443 to Cloudflare — that's the only network change needed. No security group changes. No public IP. No load balancer." 
# On any EC2 instance with internet egress:
curl -L --output cloudflared.deb \\
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <your-tunnel-token>
"Run those three commands, the instance shows up in the dashboard as a connected tunnel. Per-instance control — what I'm running on my lab right now."

Option 2: One Mesh node per VPC (subnet routing)

"What if you don't want to install software on every box? Run one Mesh node per VPC, point it at the VPC's CIDR — say, 10.0.0.0/16. Now every server, database, and resource in that VPC is reachable through that single node, with nothing installed on the rest. Great for RDP, databases, file shares, anything you can't put cloudflared on directly." 
# On one EC2 instance acting as the subnet router:
sudo apt install cloudflare-warp
sudo warp-cli connector new <token>
# In the dashboard: Networks → Mesh → Advertise routes → 10.0.0.0/16
"One install, whole VPC reachable. For HA, run two Mesh nodes in different AZs — same active-passive replica pattern you saw with cloudflared."

Option 3: Magic WAN (network-level integration)

"For larger deployments who want full SD-WAN: connect your VPC to Cloudflare over IPsec or GRE. No agents anywhere — the network itself is on Cloudflare. Bigger commitment, but it's how you'd connect data centers and large enterprise environments."
The honest framing: "Start with Option 1 for the first few apps. Move to Option 2 when you want to onboard whole subnets without touching every box. Option 3 is the long-game answer for large environments."

9. Resolvers & Proxies

▶ Networks → Resolvers and Proxies

"How DNS traffic from your network gets sent to Cloudflare. Instead of installing agents, you point routers, firewalls, or DHCP at Cloudflare DNS."

"Lightweight — start with a single location, nothing changes until you actually redirect DNS at it. Agentless way to bring existing networks under Zero Trust. No re-architecture. No VPN."

10. Access Controls — Applications

▶ Access Controls → Applications

"You just saw the eve-ng app working live. This is where I told Cloudflare it exists — and what rules users have to pass to reach it."

"Every request is evaluated in real time. Identity checked, policy enforced — before traffic ever hits the app."

"This is where it breaks from the VPN model. No 'once you're in, you're trusted.' Access is per-request, scoped to the application. You get this app. That's it — no free roam on the subnet."

11. Policies

▶ Access Controls → Policies

"Apps define what we're protecting. Policies define who gets access — and under what conditions."

"Define a policy once, reuse it across apps. Consistent and easy to manage."

"Every request evaluated in real time. The moment a user stops meeting policy — access stops. Not at the next login. Right then."

12. Service Credentials

▶ Access Controls → Service Credentials

"Quick stop here, because this is the one most teams forget. Zero Trust isn't just for people. A lot of access today is automation — scripts, CI/CD, integrations."

"Traditionally that's handled with long-lived passwords or API keys that quietly become risk over time. Service credentials fix that — machines get an identity. Tokens or certs that can be rotated and revoked."

"Machines treated just like users. Explicitly defined, allowed by policy, evaluated every time."

➡ So far we've talked about getting in. Let's flip it — what happens once a user is on the internet.

⚙ LAB NOTE — Context switch (just for me)

Heads up to self: my Linux box runs both cloudflared AND WARP. They can't both be on. Up to this point in the demo, tunnels are up, WARP is off — that's what kept eve-ng and nginx reachable for the live demo.

For the SWG section coming up, I need WARP on, tunnels off. Do this between sips of coffee while you're transitioning: 

$ stopcloud          # turn off both cloudflared connectors
$ warp-cli connect   # bring WARP up

Trade-off: while WARP is up, eve-ng.tarheel.us and nginx.tarheel.us are offline. If a customer hits refresh during the SWG section, they'll see a tunnel error. That's fine — the demo flow has moved on, just don't pivot back to the apps.

To return to ZTNA mode after the demo: 

$ warp-cli disconnect
$ startcloud

Smooth transition line for the audience (covers the pause):
"Alright — quick gear shift. We've covered how users get in. Now I want to show you what happens to their traffic on the way out."

13. Traffic Policies Overview

▶ Traffic Policies → Overview

"Cloudflare acting as a Secure Web Gateway. Controls what user traffic can do after it leaves the device."

"Traffic policies decide what's allowed, blocked, or logged across DNS and web traffic. Cloudflare sits inline and evaluates everything in real time. Disallowed? The connection just never completes."

"Same policies whether users are on the Cloudflare One client or in an office. That consistency is the win."

14. Firewall Policies (live demo)

▶ Traffic Policies → Firewall Policies

▶ Click the HTTP tab at the top (next to DNS and Network)

"I'm clicking into the HTTP tab here — that's where the Secure Web Gateway demo lives. DNS and Network policies are next to it, but HTTP is where you see web traffic being evaluated request-by-request."
"Real guardrails. Look at the Action column — not just block or allow. Block social media outright. Redirect LinkedIn to a Cloudflare-approved page. Isolate Netflix in a remote browser so users can still watch but nothing executes locally. Same policies remote or in-office."

▶ Show the firewall policy list in the dashboard. Point at the variety of actions: BLOCK, REDIRECT, ISOLATE.

"Eleven HTTP policies running right now, plus three DNS policies underneath. Four different actions: BLOCK (drop the request), REDIRECT (send the user somewhere else), ISOLATE (open the site in a remote browser), and BLOCK with custom message (block plus a tailored explanation). One platform, multiple ways to enforce policy."

LIVE — Watch every policy fire in real time

▶ Switch to the Linux terminal · run: traffic-gen

"This script hits a list of sites through Gateway. Watch the color-coded output."
"GREEN — ALLOWED. Clean traffic, no policy matched.
"RED — BLOCKED. TikTok, Facebook, X — user sees a clean block page.
"BLUE — REDIRECTED. LinkedIn, YouTube → cloudflare.com (or your LMS, HR portal).
"PURPLE — ISOLATED. Netflix, Spotify open in a remote browser. Pixel streams only.

"Same script, same network, four outcomes — decided at the edge in milliseconds."

▶ Show twitch.tv and hulu.com — custom block messages

"Both blocked, but with tailored messages. Twitch: 'blocked during work hours.' Hulu: 'streaming services blocked on corporate network.' Fewer help-desk tickets because users know why."

▶ Switch to Firefox · visit netflix.com directly

"Isolation in action. Netflix loads inside Cloudflare's remote browser — small banner at the top, otherwise identical UX. Any script, any download, any exploit runs in our cloud — not on the laptop."

▶ Pivot to dashboard · Insights → Logs → Gateway → HTTP · filter by tiktok.com

"Every decision logged. Filter by domain, see which policy fired and why."

▶ Mention DNS policies underneath

"DNS layer catches the broad obvious-bad — malware, phishing, C2, newly-registered domains, public DoH bypass attempts. HTTP handles the surgical stuff. Layered defense, one dashboard."

15. Egress Policies

▶ Traffic Policies → Egress Policies

"What the outside world sees when your users go to the internet."

"By default, Cloudflare sends traffic out from the closest egress IP. Great for performance — usually exactly what you want."

"But sometimes you need a fixed IP. SaaS app or a partner that only allows traffic from specific addresses — classic example."

"Define the rule once. Users can be anywhere on the planet, but to that external service, the traffic always looks like it's coming from a known, trusted address. That's something a VPN concentrator was the only way to get for years. Now it's a checkbox."

16. Cloud & SaaS Findings

▶ Cloud and SaaS Findings → Overview · then Posture Findings

"Quick one. This page answers one question: are my cloud and SaaS apps in a good state — or not? Connect Microsoft 365, Google Workspace, whatever — we review them with a read-only API, and we do it automatically. Nothing inline, nothing breaks. It looks for risky config, data exposure, and misconfigurations — the stuff that quietly causes problems."

17. Email Security

▶ Email Security → Overview

"Still one of the most common attack paths. Cloudflare watches email for phishing, spoofing, and BEC — behavior and patterns, not just filters. The one I really like: Retro Scan. Look back at past email and see what we would have caught without changing mail flow. Customers prove the value before flipping anything live."

18. Data Loss Prevention (DLP)

▶ Data Loss Prevention → Overview

"Protecting sensitive data — making sure it doesn't leave where it shouldn't."

"Easy scenario, easy to picture. An employee can't accidentally upload a list of Social Security Numbers to some random website. But they are allowed to upload them to Workday — because that's the HR system. Cloudflare scans traffic for those patterns and enforces accordingly."

"Most data loss isn't malicious. It's accidental. You define what 'sensitive' means — personal, financial, custom data — and protect it without relying on people to always make the right call. Because they won't. Every time."

19. Browser Isolation

▶ Browser Isolation → Overview

"Protecting users from risky websites. Instead of trusting the site, Cloudflare opens it somewhere else."

"The page actually runs in a remote browser — and a safe view is streamed back to the user. So if there's malware on that page, it never reaches the device."

"You control when isolation kicks in — unknown sites, risky categories, specific apps. And what users can do inside the session — copy/paste, downloads, printing."

"This ties directly into Gateway and Access. It's not a separate tool — it's another enforcement option."

20. Reusable Components (quick mention)

▶ Reusable Components (describe — don't click in)

"Last quick stop — and I'll just mention it. Lists and tags."

"Lists store values — IPs, domains, URLs — so policies reference them without you repeating data everywhere. Tags attach labels to things. Users, devices, networks, apps."

"Define once, use everywhere. Sounds boring, saves you hours every month at scale."

21. Closing

"What you saw today isn't a pile of security tools. It's a different access model."

"We didn't put users on a network. We didn't open ports. We didn't trust anything by default."

"Every access decision based on identity, device, and policy — enforced at the edge. Tunnel up, access worked. Tunnel down, everything stopped. Nothing else was exposed. Nothing leaked sideways."

"That's Zero Trust in practice."

"The real question isn't 'can you replace a VPN?' It's 'does your access model actually match how your business operates today?'"

⏸ Pause — let it land

"One more thing on lead times — because it always comes up. Cloudflare has no lead times. No hardware to install. Sign up today, start working today. The environment you just saw — private app, registered domain, connected to my server, accessible from anywhere on the internet — 20 minutes. Start to finish."

"Thank you for the time — happy to take a couple of questions."

Q&A — back-pocket answers

Zero Trust & Access Model

What is Zero Trust? Nothing trusted by default. Every request verified by identity, device, and policy.

Zero Trust vs. perimeter security? Perimeter trusts whatever's inside the network. Zero Trust never assumes trust based on location.

Zero Trust vs. VPN? VPNs put users on a network. Zero Trust gives access only to specific apps.

What problems does it solve VPNs can't? Lateral movement, blast radius from stolen credentials.

Product or strategy? Strategy — implemented through tools and policies.

If credentials are compromised? Device posture, re-auth, and policy still block access.

Where does Zero Trust fail? When identity, devices, or policies are too permissive.

📊 Show them the visual: The Case for Zero Trust — visual comparison

Contractors & Third-Party Access

How do contractors get in without a VPN? Cloudflare Access. They log in with their own identity (Google, GitHub, Microsoft, email OTP), get scoped to the specific apps they need — nothing else. No agent install required for web apps.

What about temporary or time-limited access? Set an expiration on the policy. Access automatically revokes at the date/time you specify. No cleanup tickets, no forgotten accounts.

What if they need access for one project, then it's done? Tag the policy by project. When the project ends, remove the rule. Their access ends instantly across every app tied to that policy.

Can I onboard a contractor in minutes? Yes. Add their email to an Access group → assign the group to specific apps → send them the URL. They log in via their existing identity provider or get an email OTP. No accounts to provision in your AD, no laptop to ship.

How do I know what a contractor did? Every access request logged — who, what, when, from where. Filter by user in Logs. Full audit trail with no extra tooling.

Can I require a managed device? Yes — device posture checks. Or, for unmanaged contractor laptops, route them through Browser Isolation so nothing executes locally on their device.

What if the contractor is hostile or compromised? Disable them in your IdP, or just remove them from the Access group. Their session is terminated. No "they might still have VPN credentials cached somewhere" problem.

📊 Show them the visual: Contractor onboarding flow · Browser Isolation in action

Bottlenecks Today vs. With Cloudflare

Scan the left column for the complaint they just said. Read the right column out loud.

If they say... You say...
"VPN slow at 9am Monday." Classic concentrator over-subscription. No concentrator with us — enforcement at 330+ edges.
"Branch offices complain about HQ-routed traffic." Backhaul pattern. We put edge enforcement in their region — no detour.
"Our security stack is a chain of appliances." Service-chain bottleneck. DDoS, WAF, Bot, SWG, DLP, Isolation — all at one edge hop.
"Apps in us-east, users global." Geographic distance + transit congestion. Edge enforcement + Argo Smart Routing.
"Works in office, not at home." Last-mile ISP routing. Argo routes around bad links in real time.
"Cloud uploads are killing us." Single egress chokepoint. R2 + edge-aware uploads. Zero egress fees.
"Performance varies by user location." Centralized architecture. We normalize the experience — same edge everywhere.

📊 Show them the visual: VPN vs Zero Trust diagram (covers all the scenarios above)

Cloudflare Platform

How does Cloudflare enforce Zero Trust? Policy enforcement at the edge — identity, device posture, context.

What's different? Global edge, not backhauled to a data center.

Replace a VPN? Yes, for most user-to-app access.

Operational benefit? Fewer tools, fewer rules, simpler troubleshooting.

Cloudflare Tunnel

What is it? Outbound-only connection from private apps to Cloudflare.

Why outbound-only? No inbound firewall rules. No exposed IPs.

What if it goes down? Access stops. Nothing exposed. (You demoed this live.)

📊 Show them the visual: Onboarding internal servers — three patterns

Cloudflare Mesh

What is it? Private networking between devices and servers. Everything gets a private IP and can talk to anything else.

Like Tailscale? Same idea. Difference: traffic goes through Cloudflare so policies and identity checks apply.

Mesh vs. Tunnel? Tunnel publishes an app. Mesh connects everything. Use Mesh for databases, RDP, SAP — anything needing long-lived TCP.

Where in the dashboard? Networks → Mesh.

📊 Show them the visual: Onboarding flows — Mesh tab

Cloudflare One Client (WARP)

Is the Cloudflare One client a VPN? No — doesn't place users on a network. (This is the new name for what you may have known as WARP.)

Difference vs. VPN client? Traffic is policy-checked at the edge, not tunneled to a LAN.

What does it protect? Internal apps, SaaS, internet traffic.

📊 Show them the visual: End-user login experience

DDoS, WAF, Bots

DDoS — always on? Yes, automatic.

WAF — different from traditional? No appliances, no scaling limits, automatic updates.

Bot management? Distinguishes automation from humans. Stops credential stuffing.

Logging & Visibility

Why centralized? No correlating across multiple tools. Faster incident response.

Architecture

If a Cloudflare DC fails? Anycast — traffic shifts to the next closest location.

Why edge enforcement is more resilient? Failures are localized, not global.

📊 Show them the visual: Global network map (330+ cities) · Argo smart routing

Business / Executive

Why Cloudflare over point products? One platform vs. many tools.

Cost? Less hardware, fewer licenses, less ops overhead.

UX? Faster access, no VPN friction.

Explain ZT to an exec? "Access is limited to what you need, nothing more."

📊 Show them the visual: Cost calculator · VPN vs Zero Trust diagram

Curveballs

Biggest misconception about ZT? That it's a product you buy.

What doesn't Cloudflare replace? SIEMs, application-level security logic.

Why do breaches still happen? Stolen credentials, excessive trust.

🔨 "Isn't this just another VPN client to install?" — DROP THE HAMMER
Open with this — slow it down, look them in the eye:
"Same form factor. Completely different architecture.
The right question isn't 'is this another VPN client?' —
it's 'what do I get to uninstall when I deploy this?'"

Then back it up with these three counters — fast, one at a time:

Counter 1
Often no client at all
 Most internal apps are web apps. Users just hit a URL — auth via IdP — they're in. VPN clients are mandatory. Ours are optional for web.
Counter 2
One replaces many
 Our client typically replaces: VPN client + SWG agent + DNS filter + sometimes CASB. The endpoint gets simpler, not more crowded.
Counter 3
Users feel faster, not slower
 Traffic routes to the nearest of 330+ edges, not a concentrator in HQ. We resolve DNS faster than most ISPs. Users tell us the internet feels faster after install.
⚡ The kill shot — say this AFTER the three counters
"VPN clients install software so you can pretend you're inside a network. Our client installs software so you can stop pretending. That's not the same thing wearing different paint."
Delivery note: Don't rush. Pause after the opener. Pause after each counter. Pause before the kill shot. Confidence = silence. If they push back after this, you've already won — they're negotiating, not rejecting.

📋 Follow-up answers — questions from the call

Plain-English answers you can deliver naturally. No memorization needed — read it once, then say it your way. Each item links to the relevant visual demo when applicable.

1. (Oscar) What's the difference between Cloudflare's CDN/DNS stuff and Zero Trust?
🎬
Open this in a new tab while you answer
→ cf-demo-app.dustinburke23nc.workers.dev/cdn-vs-zerotrust
Animated comparison · public CDN/DNS pipeline vs Zero Trust pipeline · side-by-side view

Same network, different jobs.

Our CDN and DNS sit in front of your public website — like a bouncer at the door. Anyone on the internet can show up, and we filter the bad stuff out before it reaches your servers.

Zero Trust is for everything that isn't public — your internal apps, your databases, your developer tools. There's no door for the internet to knock on. Users get verified by identity, then we let them in to the specific thing they need.

Example: your marketing site uses our CDN. Your internal HR portal uses Zero Trust. Same Cloudflare account, same dashboard, totally different traffic patterns.

2. (Oscar) Can we use Cloudflare for RDP and SSH to internal servers?
🎬
Open this in a new tab while you answer
→ cf-demo-app.dustinburke23nc.workers.dev/browser-ssh-rdp
Animated SSH terminal + Windows RDP desktop · live audit log · policy enforcement

Yes, two ways.

The easy way: users open a URL in their browser, log in, and get a working RDP or SSH session right there in the browser tab. No PuTTY, no Remote Desktop client, no agent install. Works from any laptop.

The power-user way: if your developers want to use their normal SSH client, they can. Cloudflare just makes sure the connection goes through identity and policy checks first.

Example: a contractor needs RDP into a production Windows box. You send them a URL. They log in with their Google account. They're in. You see every keystroke logged. When the project ends, the URL stops working.

3. (Paul) India developer to AWS East — doesn't the traffic still cross the globe?

Honest answer: yes. We can't break physics. If the server is in Virginia and the user is in Mumbai, the bits still have to go between them.

But we change how they make the trip:

Example: a Mumbai developer pulling logs from an AWS East server. On a normal VPN that's about 280ms per request. Through us, it's around 145ms. Not zero — but cut in half.

If they push back: "Let's run a real test on your traffic for a week. I'll show you the actual numbers, not my marketing numbers."

📊 Visual: VPN vs Zero Trust diagram → click "Do the math · Latency" tab for the hop-by-hop breakdown.

4. (Oscar) How do I get my EC2 instances onto the Cloudflare network?

Three ways, depending on how much you want to install where.

The important part: in all three patterns, your servers only make outgoing connections to us. You don't open any firewall ports for the internet to reach them. There's nothing exposed.

📊 Visual: Onboarding internal servers — three patterns, animated diagrams

5. What about contractors who can't install our security client?

They don't have to. That's actually our strongest story for external users.

You send them a URL. They open it in any browser. They sign in with their own Google or Microsoft account — whatever they already have. They're in. Scoped to just the app you allowed.

You can set the access to expire automatically when the project ends. No tickets to clean up. No forgotten accounts sitting in your AD.

Example: you bring in three contractors for a Q4 audit. You give them a URL and assign them to the "Q4 audit" group. They use their own laptops. When December 31 hits, the URL stops working for everyone in that group. Done.

📊 Visual: Contractor onboarding flow — split-screen, animated

6. Are you really faster than our VPN?

For most users, yes — usually noticeably faster.

A traditional VPN sends every user's traffic to one or two appliances at your headquarters. If you're a developer in London accessing an app in London, your traffic goes London → Texas → London → Texas. That's the speed problem.

We have data centers in 330+ cities. The user connects to the one closest to them. Policy gets enforced right there. Then traffic takes the shortest path to the app. No detour through your HQ.

Example: a sales rep in Singapore opens your internal CRM. On the VPN, that's a 300ms round trip through your US data center. Through us, it's 90ms because we enforce in Singapore. They feel the difference immediately.

How big the win is depends on how spread out your team is. If everyone's in one office, we're only a little faster. If you have a hybrid workforce across multiple continents, we're a lot faster.

📊 Visual: VPN vs Zero Trust · Global network map (330+ cities)

7. Can we see this with diagrams instead of dashboard demos?

Yes — I built a set of visual diagrams specifically for this. Click any of them:

For a 12-minute guided architecture walkthrough that hits multiple: Guided demo flow

For static slides: screenshot each demo, drop into a 3-slide deck, send as a follow-up.

8. How exactly does Magic WAN connect — what's the link?

Magic WAN hooks your network to Cloudflare at the router level — no software on any laptop or server. Four ways to make the connection:

What you get once connected: Cloudflare becomes both your network's on-ramp to the internet (Gateway, DLP, filtering) and the path between your sites. Branch-to-branch traffic flows through Cloudflare's backbone instead of MPLS.

Example: you have an AWS VPC in us-east-1, an office in Atlanta, and a data center in Dallas. Set up one IPsec tunnel from each — three tunnels total. Now anything in any of those three places can reach anything in the other two, securely. You retire MPLS. You retire the VPN concentrator. Network team configures it all in our dashboard.

When to use Magic WAN vs. Tunnel/Mesh:

📊 Visual: Onboarding flows — Magic WAN tab shows all four connection methods.